Bring back iOS application delegates and fix many issues #6453
Conversation
Disabling UIKit event pump prevents the app from receiving general app notifications. See: https://github.com/libsdl-org/SDL/blob/45fc548562d7313e0066b99ca7279935e90e4fb1/src/video/uikit/SDL_uikitevents.m#L52-L66
|
I think this is fine conceptually, because this is the default sort of implementation one would expect of Xcode's templates etc... Curious if @Susko3 has any thoughts (even though you're a bit more on the Android side of things). |
| public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation) | ||
| { | ||
| // copied verbatim from SDL: https://github.com/libsdl-org/SDL/blob/d252a8fe126b998bd1b0f4e4cf52312cd11de378/src/video/uikit/SDL_uikitappdelegate.m#L508-L535 | ||
| // the hope is that the SDL app delegate class does not have such handling exist there, but Apple does not provide a corresponding notification to make that possible. |
There was a problem hiding this comment.
Is there some copy-paste error in this comment? I don't really understand what it's supposed to say.
There was a problem hiding this comment.
There is no error, there are just some iOS terminologies mixed in the comment. Apple provides things called Notifications in the iOS frameworks which allow applications to intercept events happening on any existing NSObject (i.e. any object), as long as said object exposes said Notifications (there's more into this but I don't want to dwell any further).
The key point of this comment is that some functionalities that used to exist in SDLUIKitDelegate were moved out to "observer" notification handlers to keep SDL away from the AppDelegate class. See libsdl-org/SDL#6011 (comment). However, there's no equivalent notification for handling OpenUrl outside of AppDelegate class, hence the existence of this comment and the copy-pasted code.
|
|
||
| namespace TemplateGame.iOS | ||
| { | ||
| /// <inheritdoc /> |
There was a problem hiding this comment.
Is [Register("AppDelegate")] missing here?
Why is it required in the first place?
There was a problem hiding this comment.
The attribute is inserted by default into every created iOS project, I did not delve deep into why it's required but I wouldn't want to defy what .NET/Xamarin does so /shrug. Will fix the missing specification.
There was a problem hiding this comment.
I'm mostly worried about SDL changing their SDLUIKitDelegate and us not following with that change. It's also possible that SDL stops working if it's not given a SDLUIKitDelegate.
In any case, if this goes in, someone should probably point their RSS reader at https://github.com/libsdl-org/SDL/commits/main/src/video/uikit/SDL_uikitappdelegate.m.atom and watch for any breaking changes.
| return 0; | ||
| public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation) | ||
| { | ||
| // copied verbatim from SDL: https://github.com/libsdl-org/SDL/blob/d252a8fe126b998bd1b0f4e4cf52312cd11de378/src/video/uikit/SDL_uikitappdelegate.m#L508-L535 |
There was a problem hiding this comment.
Could you subclass SDLUIKitDelegate? Seems to be supported by SDL. Maybe we don't want the extra baggage that comes from the SDL implementation?
There was a problem hiding this comment.
This was the hope at first but it was an extremely complicated process. We haven't explored through the concept of "iOS binding projects" before, which is an essential key to expose such types in the C# world. And throughout a brief attempt from my end, it cannot be integrated within the SDL3-CS project, it has to be in a separate project, either SDL3-CS.iOSBindings or osu.Framework.iOS.SDLBindings, depending on what the end goal with the iOS binding project turns out.
It will be a multi-day effort with back-and-fourth discussions on where and how should it be implemented and whether it's going to cause issues if it's a separate project (looping back to the concern about the Android project being previously separate), so I ultimately gave up on it on the trust that SDL will not silently add crucial code in SDLUIKitDelegate.
It looks to me that the entire SDL system is completely detached from the running app delegate class. I don't see the type mentioned anywhere other than in the file itself, and the current implementation of that class shows almost nothing crucial to the initialisation of the system (save for the URL handling code, which doesn't seem like it can be done any other way). I have set up the linked RSS feed to see if SDL will tell me otherwise. |
That hint is handled by a separate component |
After going through separate issues that ask for having access to a custom app delegate class, and specifically after #6449 / libsdl-org/SDL#11627, I've looked into bringing app delegate classes back.
Reading the SDL's codebase and various PRs in the repo, I've noticed that SDL intentionally doesn't do anything special/internal for its API in the app delegate class it uses for the application. This is to allow consumers that wish for a custom app delegate class to create one without extra effort (although I had to do this 3134295).
In order to use SDL without their own app delegate class, the
SDL_RunAppshould be omitted and we should callUIApplication.Mainon our app delegate class directly instead, and atfinishedLaunching, we just have to callSDL_SetMainReadyto mark it as ready for initialisation.For detailed reasons as to why this PR exists:
GameApplication.main. Disabling the UIKit event pump causes the application to not receive will/did enter background/foreground events, therefore never suspending/unfocusing when sent to background.UIApplicationDelegateclass to control the list of allowed orientations, to add support for Disable screen rotation while in active gameplay osu#5331UIApplicationDelegateclass is mandatory to have in any application for full flexibility over the app's configuration/behaviour, as well as handling various app-level events which may otherwise require asking SDL to add while not being of priority to them.